Support a .noinit section for variables#996
Merged
fpistm merged 1 commit intostm32duino:masterfrom Mar 19, 2020
Merged
Conversation
This is inspired by the linker sripts on the AVR architecture, which
support a .noinit section (or any section starting with .noinit,
actually) for variables that should be allocated an address in RAM, but
not be initialized to any particular value (not even zero) on startup.
These can then be used to remember values across resets.
From the sketch perspective, this works exactly the same as on AVR: Just
annote a global variable with `__attribute__((__section__(".noinit")))`
and it will have an unpredictable value on power-up and retain its value
during resets.
To implement this without having to change all board-specific linker
scripts, the linker commandline is changed to pass the board-specific
linker script to the `--default-script` linker script, and change the
main linker script (passed to `--script`, previously `-T`) to a generic
"override" linker script. This new generic linker script contains an
`INSERT BEFORE` command, which causes the linker to load it *in addition
to* the default linker script, while adding an extra `.noinit` output
section in the right place.
Because these new variables take up RAM but have their own section in
the .elf file, they should be accounted for in the size summary after
compilation. This is done by adapting the `recipe.size.regex.data` entry
to include this new section.
Member
|
@matthijskooijman |
Contributor
Author
|
Thanks for the quick merge :-)
Of course, any suggestion on where would be appropriate? I was thinking maybe here: https://github.com/stm32duino/wiki/wiki/API and then make a new section "Other" (on the same level as "Built-in library") with "Uninitialized variables" under there? |
Member
|
Sound good for me. |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is inspired by the linker sripts on the AVR architecture, which
support a .noinit section (or any section starting with .noinit,
actually) for variables that should be allocated an address in RAM, but
not be initialized to any particular value (not even zero) on startup.
These can then be used to remember values across resets.
From the sketch perspective, this works exactly the same as on AVR: Just
annote a global variable with
__attribute__((__section__(".noinit")))and it will have an unpredictable value on power-up and retain its value
during resets.
To implement this without having to change all board-specific linker
scripts, the linker commandline is changed to pass the board-specific
linker script to the
--default-scriptlinker script, and change themain linker script (passed to
--script, previously-T) to a generic"override" linker script. This new generic linker script contains an
INSERT BEFOREcommand, which causes the linker to load it in additionto the default linker script, while adding an extra
.noinitoutputsection in the right place.
Because these new variables take up RAM but have their own section in
the .elf file, they should be accounted for in the size summary after
compilation. This is done by adapting the
recipe.size.regex.dataentryto include this new section.
I originally implemented this for the reset-to-bootloader in #710, but I think this is useful by itself as well, for sketches to use, even when #710 might not end up using this. Also, since this is distinct feature, it helps unclutter #710 by merging this separately.
To test it, consider the following sketch:
This shows the number of boots since the last POR by incrementing a noinit variable across resets. Note that when you first upload this, it might not start at 1 but at some arbitrary value, because typically the first boot after an upload is not a power-on-reset. To start at 1, disconnect and reconnect power.